【レポート】IOT321 | AWS IoT CoreとMQTTによるトヨタのコネクテッドプラットフォーム変革 #AWSreInvent #IOT321
製造ビジネステクノロジー部の新澤です。
"Toyota's connected platform transformation with AWS IoT Core and MQTT"に参加してきましたので、レポートします。
本セッションについて
- タイトル: Toyota's connected platform transformation with AWS IoT Core and MQTT
- Level: 300 – Advanced
- Speaker: Roman Tubin (AWS), Daisuke Muramoto (Toyota), Hiroshi Kamada (Toyota)
概要
本セッションでは、トヨタのコネクテッドビークルプラットフォームの変遷と、プラットフォームの技術的な詳細についての紹介が行われました。
最初にAWSのRoman氏より、コネクテッドビークルの概念の紹介とAWSの「5Q」コンセプトを通じて製品戦略を構築することについて説明されました。
次に、トヨタのMuramoto氏よりトヨタコネクテッドビークルプラットフォームの概要とユースケース、技術的な変遷について紹介され、続いて、トヨタのKamada氏よりSMSからMQTT5に移行した詳細について紹介されました。
アジェンダ
- 01 Intro
- 02 Connected vehicle platforms with AWS
- 03 Introduction to Toyota's Connected Vehicle Platform
- 04 Toyota's transformation with AWS IoT Core and MQTT5
01 Intro
AWSが考える「5Q」コンセプトについて説明されました。
このコンセプトは、製品戦略を体系的に構築し、顧客中心のソリューションを開発するための指針となるもの。
5つの質問(5Q)の概要は以下:
-
誰が顧客か?
- エンドユーザー(ドライバー)
- 車両所有者
- 車両オペレーター(カーシェアリング事業者など)
-
顧客のニーズは何か?
- 安全性
- 車両の保護
- コスト効率
- 利便性(安心感)
-
これらのニーズをどのように解決するか?
- AWS IoT Coreを中心とした、エッジからクラウド、クラウドからエッジへの通信
- セキュリティとプライバシーの確保
- リアルタイムのモニタリングと遠隔操作
-
顧客体験をどのように構築するか?
- 3つの要素を組み合わせた使用事例の創出
- アラート
- 車両の監視
- 遠隔制御
- 3つの要素を組み合わせた使用事例の創出
-
成功をどのように測定するか?
- 「制御可能なインプット」に焦点を当てる
- 顧客体験の向上
- イノベーションの加速
- コストの削減
02 Connected vehicle platforms with AWS
続いて、トヨタのMuramoto氏による同社のコネクテッドビークルプラットフォームについて紹介されました。
この図は、トヨタの製品、ホームおよび顧客向けの接続サービスとの関係を要約したものだそうです。
- コネクテッドビークルプラットフォームの3つの主な顧客メリット:
- 天気情報、ニュース、地図、交通情報の取得
- 車両のリモート操作と状態確認
- 運転データ分析による保険サービスの提供
- 代表的な3つのユースケース:
- SOSサービス(緊急時のオペレーターへの接続)
- リモートコントロール(エアコン起動、ドアロックなど)
- ドライビングスコア(安全運転度の計算と保険サービス)
ちなみに、ドライビングスコアに表示されているのは、デモ用の値ではなくMuramoto氏の実際のものだそうです。(100点!)
03 Introduction to Toyota's Connected Vehicle Platform
- コネクテッドビークルプラットフォームの歴史:
- 2002年:テレマティクスサービス開始(オンプレミス)
- 2016年:クラウドサービス利用開始
- 2019年:サーバーレスアーキテクチャへの移行
- 2020年:ビッグデータ製品の実装
- 2021年:セキュリティ製品の導入
- 現在:IoT Coreの実装と継続的な改善
04 Toyota's transformation with AWS IoT Core and MQTT5
ここからはトヨタのKamada氏よりMQTTの採用理由について紹介されました。
- システム開発の主な目的:
- 迅速な開発と低コスト
- 顧客に快適なUXサービスの提供
- 安定で信頼性の高いサービスの実現
-
従来のSMSアプローチの課題:
- 遅延の問題
- コスト面の制約
- キャリアごとの地域契約の必要性
- データ容量の制限
-
MQTTアプローチの利点:
- リアルタイムデータ伝送
- 軽量なデータ構造
- サードパーティを介さない直接通信
- スケーラビリティ
- 低コスト
- 安定したマネージドサービス
-
アーキテクチャの変化:
- IoT Coreをブローカーとして使用
- サーバーサイドアプリケーションをパブリッシャー、車両をサブスクライバーとして配置
-
プロトコルの併用:
- MQTT: リアルタイム通信
- HTTP: 大容量データアップロードと既存APIとの通信
-
導入メリット:
- 簡素で高速な通信
- リアルタイムでのスケーリング
- 最小限のプログラミングでサーバーレス実現
- MQTT v5の主要な新機能:
- リクエスト・レスポンスモデル
- メッセージにプロパティを設定可能
- レスポンストピックの実装
- 相関データ(トランザクションID)の設定
- リクエスト・レスポンスモデル
- リクエスト・レスポンスモデルアーキテクチャ:
- 車両からのアラーム送信
- アラーム受信の確認
- 次の処理への連続的な移行
- 共有サブスクリプション機能:
- メッセージを1つのサブスクライバーのみに配信(ファンアウトさせない)
- サーバーサイドの処理負荷分散
- 大規模メッセージ処理の実現
- 従来のSQSとLambdaアプローチからの改善
- 将来の展望:
- 車載器からモバイルアプリへのエンドツーエンドMQTT通信
- プッシュサーバー不要
- よりシンプルで直接的な対話
- レスポンシブなユーザー体験の提供
-
高可用性の必要性
- 特に緊急情報などの重要な機能では高可用性が不可欠
-
アーキテクチャの設計方針
- 複数のAWSリージョンにわたる展開
- アクティブ構成の採用
-
具体的な実装方法
- 車載器
- 事前に定められたルールに従い、1つのリージョンに接続
- サーバーサイドアプリケーション
- 両リージョンを同時に購読
- 車載器
-
障害時の対応
- 1つのリージョンで障害が発生した場合、車載器は自動的に別のリージョンに再接続
-
設計上の考慮点
- システム構造のシンプルさを優先
- コスト効率を重視
- 追加のプログラミングを最小限に抑える
-
目標
- サービス継続性の確保
- 予期せぬ障害への備え
- シンプルかつ高コスト効率
-
目的
- 車載器とサーバーサイド間の接続の信頼性確保
- なりすまし防止
- セキュアな通信の実現
-
認証強化のアプローチ
- 二重チェック方式の採用
- 車両の識別情報と認証情報の照合
-
認証プロセスの詳細
- トランスポート層とアプリケーション層の両方で認証を強化
- AWS IoT Coreの設定ページに基づく
- カスタム認証プロセスをLambdaで実装可能
感想
トヨタのコネクティッドビークルプラットフォームの取り組みについて、オンプレミス構成からの変遷の話を聞くことができ、大変興味深かったです。
また、MQTT v5の活用方法についても参考になりました。